IRIX Base Documentation 1998 November/IRIX 6.5.2 Base Documentation November 1998.img/usr/share/catman/u_man/cat1/rld.z/rld

Text File | 1998-10-30 | 36KB | 661 lines

RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



NNNNAAAAMMMMEEEE
     rld - runtime linker
     rld.debug - runtime linker with debugging support

DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
     _r_l_d, the runtime linker, exists in appropriate versions for executables
     in each ABI (Application Binary Interface) available.  _r_l_d is invoked
     when running a dynamic executable. _r_l_d maps in shared objects used by
     this executable, resolves relocations as _l_d does at static link time, and
     allocates common if required.

     When any dynamic executable is run, the system will first run an
     interpreter which is responsible for collecting together the appropriate
     objects, mapping them into memory and resolving references during
     runtime. The name of the interpreter is included in the executable file.
     Dynamic execution is only supported with ELF format executables. Such
     executables will have an INTERP section which specifies the name of this
     interpreter.  The default name of this interpreter is /_u_s_r/_l_i_b/_l_i_b_c._s_o._1.
     Any binary which hopes to conform to the MIPS SVR4 ABI should use the
     name /_u_s_r/_l_i_b/_l_i_b_c._s_o._1 as its interpreter.

     For 64-bit (64-bit ABI) programs the name of this interpreter is
     /_u_s_r/_l_i_b_6_4/_l_i_b_c._s_o._1.  The discussion below applies to 64-bit programs if
     the directory /_u_s_r/_l_i_b_6_4 is substituted for the directory  /_u_s_r/_l_i_b and
     the directory /_l_i_b_6_4 is substituted for /_l_i_b.

     For new 32-bit ABI programs the name of this interpreter is
     /_u_s_r/_l_i_b_3_2/_l_i_b_c._s_o._1.  The discussion below applies to new 32-bit ABI
     programs if the directory /_u_s_r/_l_i_b_3_2 is substituted for the directory
     /_u_s_r/_l_i_b and the directory /_l_i_b_3_2 is substituted for /_l_i_b.

     The file /_u_s_r/_l_i_b/_l_i_b_c._s_o._1 is the standard C/system library in the form
     of a shared object. In addition /_u_s_r/_l_i_b/_l_i_b_c._s_o._1 contains code which
     will load the interpreter into its address space and set it to work.  The
     default such interpreter is /_l_i_b/_r_l_d.

     One of the primary features of dynamic linking is that it gives users the
     ability to change library implementations without recompiling the
     executable. Some mechanisms for this are listed below.  However,
     /_u_s_r/_l_i_b/_l_i_b_c._s_o._1 is not subject to any of the mechanisms listed below,
     since it is known to the executable as the interpreter as well as a
     needed shared object. If you wish to substitute /_u_s_r/_l_i_b/_l_i_b_c._s_o._1, the
     best way is to make use of the -_I flag to the linker (_l_d(1)).  This can
     be passed from the compiler driver using the -_W_l,-_I,_m_y_i_n_t_e_r_p_n_a_m_e format.
     However, any such shared object specified must be able to act as
     interpreter (or invoke _r_l_d).

     _r_l_d constructs an explicit shared object list based on the information
     listed in the .liblist section.  For 32-bit programs, if the environment
     variable ____RRRRLLLLDDDD____LLLLIIIISSSSTTTT is set, it overrides the dynamic executable's original
     list (after the original list is constructed).  The corresponding
     environment variable for 64-bit programs is ____RRRRLLLLDDDD66664444____LLLLIIIISSSSTTTT,,,, and the one for



                                                                        PPPPaaaaggggeeee 1111






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     new 32-bit ABI programs is ____RRRRLLLLDDDDNNNN33332222____LLLLIIIISSSSTTTT....

     For n32 (new 32-bit ABI) or 64-bit (64-bit ABI) programs, if _RLDN32_LIST
     or _RLD64_LIST is not specified, then rld will honor _RLD_LIST if
     specified.

     The user may include DDDDEEEEFFFFAAAAUUUULLLLTTTT in _RLD_LIST (_RLDN32_LIST/_RLD64_LIST) to
     include the executable's original objlist and have rld to add new shared
     objects just before and/or after it.  The object list is specified as a
     colon (:) separated list of shared objects.  The liblists of shared
     objects newly added from _RLD_LIST, _RLDN32_LIST, or _RLD64_LIST are
     intentionally not processed:  so it is up to the user to make the list
     complete.

     Because there are three distinct ABI's used by Irix programs with
     accompanying libraries, there are three distinct sets of RLD search paths
     and three sets of environment variables.

     The default library search path for o32 (32-bit ABI) programs is
     (/_u_s_r/_l_i_b:/_u_s_r/_l_i_b/_i_n_t_e_r_n_a_l:/_l_i_b), which can be overridden by either of
     the environment variables ____RRRRLLLLDDDD____RRRROOOOOOOOTTTT or LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH....

     The default library search path for 64 (64-bit ABI) programs is
     (/_u_s_r/_l_i_b_6_4:/_u_s_r/_l_i_b_6_4/_i_n_t_e_r_n_a_l:/_l_i_b_6_4), which can be overridden by
     either of the environment variables ____RRRRLLLLDDDD66664444____RRRROOOOOOOOTTTT or LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY66664444____PPPPAAAATTTTHHHH....

     The default library search path for n32 (new 32-bit ABI) programs is
     (/_u_s_r/_l_i_b_3_2:/_u_s_r/_l_i_b_3_2/_i_n_t_e_r_n_a_l:/_l_i_b_3_2), which can be overridden by
     either of the environment variables ____RRRRLLLLDDDDNNNN33332222____RRRROOOOOOOOTTTT or LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYYNNNN33332222____PPPPAAAATTTTHHHH....

     For n32 or 64-bit programs, if LD_LIBRARYN32_PATH or LD_LIBRARY64_PATH is
     not specified, then rld will honor LD_LIBRARY_PATH if specified.  As a
     result, if LD_LIBRARY_PATH is set for an o32 program it is a very good
     idea to also set LD_LIBRARYN32_PATH and LD_LIBRARY64_PATH to something
     ("" will suffice) to avoid having LD_LIBRARY_PATH apply accidentally to
     n32 and 64 applications in that environment.

     The search path for shared objects is acquired in the following order:

     1.   The path of the shared object if given in the liblist,
          (i.e., if the _s_o_n_a_m_e of the shared object has a path (see _l_d(1));

     2.   DT_RPATH if DT_RPATH is defined in the executable or
          any DSO that _r_l_d has opened.

     3.   Use LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH if defined in the environment at
          the time of execution;

     4.   The default library search path.






                                                                        PPPPaaaaggggeeee 2222






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     DDDDTTTT____RRRRPPPPAAAATTTTHHHH is a colon(:) separated list of directories.  DDDDTTTT____RRRRPPPPAAAATTTTHHHH in the
     library search algorithm outlined above refers to the net list of paths
     at the time the search is done.  DDDDTTTT____RRRRPPPPAAAATTTTHHHH is actually a tag in the
     ._d_y_n_a_m_i_c section of a DSO or executable whose value is a string.
     DDDDTTTT____RRRRPPPPAAAATTTTHHHH is set in any given DSO or the executable via the ----rrrrppppaaaatttthhhh switch
     to _l_d(1) when the executable or DSO is created.  Each DDDDTTTT____RRRRPPPPAAAATTTTHHHH appends to
     the list of directories at the time the executable or DSO is loaded.
     There is no mechanism to remove anything from the list of directories
     which rrrrlllldddd builds for the executable.

     LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH is a colon(:) separated list of directories; and, if
     defined, specifies an extra set of directories in which rld is to look
     when searching for shared objects.

     LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY66664444____PPPPAAAATTTTHHHH and LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYYNNNN33332222____PPPPAAAATTTTHHHH are treated in a similar
     fashion.

     ____RRRRLLLLDDDD____RRRROOOOOOOOTTTT is a colon(:) separated list of directories; and, if defined,
     is appended to the front of DT_RPATH and the default path.

     ____RRRRLLLLDDDD66664444____RRRROOOOOOOOTTTT and ____RRRRLLLLDDDDNNNN33332222____RRRROOOOOOOOTTTT are treated in a similar fashion.

     To ensure compatibility, applications may choose to disallow exec-time or
     runtime library replacement.  _l_d supports the -_n_o__l_i_b_r_a_r_y__r_e_p_l_a_c_e_m_e_n_t,
     flag to facilitate this feature.

     Security dictates that _r_l_d should not allow library replacement for
     _s_e_t_u_i_d and _s_e_t_g_i_d programs unless the user is _r_o_o_t.

     Users can replace the default _r_l_d binary by setting the environment
     variable ____RRRRLLLLDDDD____PPPPAAAATTTTHHHH to the full path of another runtime linker.  _r_l_d._d_e_b_u_g
     is a version of _r_l_d that has debugging support.  By setting the
     environment variable ____RRRRLLLLDDDD____PPPPAAAATTTTHHHH to /usr/lib/rld.debug, it replaces the
     default _r_l_d as the runtime linker, and the debugging features it supports
     are available.

     For 64-bit programs, the environment variable is ____RRRRLLLLDDDD66664444____PPPPAAAATTTTHHHH and the
     debugging version of rld is /usr/lib64/rld.debug.

     For new 32-bit ABI programs, the environment variable is ____RRRRLLLLDDDDNNNN33332222____PPPPAAAATTTTHHHH and
     the debugging version of rld is /usr/lib32/rld.debug.

     rrrrlllldddd also supports the environment variable LLLLDDDD____BBBBIIIINNNNDDDD____NNNNOOOOWWWW as documented in
     the SYSTEM V ABI pg 5-14. If LLLLDDDD____BBBBIIIINNNNDDDD____NNNNOOOOWWWW is set to "1" or "on", then the
     dynamic linker processes all relocation before transferring control to
     the program, if LLLLDDDD____BBBBIIIINNNNDDDD____NNNNOOOOWWWW is set to "0" or "off", or does not occur in
     the environment, then the dynamic linker is permitted to perform symbol
     resolution and relocation for functions lazily, ie avoid them until the
     functions are called.






                                                                        PPPPaaaaggggeeee 3333






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     RRRRuuuunnnnttttiiiimmmmeeee lllliiiinnnnkkkkiiiinnnngggg iiiinnnntttteeeerrrrffffaaaacccceeee

     The system calls _d_l_o_p_e_n(3), _d_l_s_y_m(3), _d_l_c_l_o_s_e(3), _d_l_e_r_r(3)
     _s_g_i_d_l_o_p_e_n__v_e_r_s_i_o_n(3) and _s_g_i_d_l_a_d_d(3) are provided to supply users with
     on-demand loading of objects.  These routines are found in
     /_u_s_r/_l_i_b/_l_i_b_c._s_o._1; no special flags are needed at link time to access
     them.

     _r_l_d ooooppppttttiiiioooonnnnssss

     Users may specify runtime linker options by setting the ____RRRRLLLLDDDD____AAAARRRRGGGGSSSS
     environment variable to any combination of the following options.  rrrrlllldddd
     options are not needed to run properly coded and linked executables: they
     are provided for special situations and debugging.

     ----cccclllleeeeaaaarrrrssssttttaaaacccckkkk
          For programs that assume local variables to be initialized to zero
          upon function entry, this option forces _r_l_d to zero any stack it
          uses before before calling the program's main program.  Properly
          written programs never assume that the stack is zeroed (therefore
          properly written programs do not expect local variables to be
          automatically initialized except as provided for in the
          programming-language definition).  If a program or any of its DSOs
          (as seen at startup of the program) dynamic section flags do not
          have RHF_SGI_ONLY set then ----cccclllleeeeaaaarrrrssssttttaaaacccckkkk is automatically turned on.

     ----iiiiggggnnnnoooorrrreeee____aaaallllllll____vvvveeeerrrrssssiiiioooonnnnssss
          ignore versions on all objects.

     ----iiiiggggnnnnoooorrrreeee____vvvveeeerrrrssssiiiioooonnnnshared_object
          ignore the version stamp checking on the object specified.  This
          option can be specified multiple times (in case multiple shared
          objects should have their versions ignored).

     ----iiiiggggnnnnoooorrrreeee____uuuunnnnrrrreeeessssoooollllvvvveeeedddd
          doesn't complain or abort when _r_l_d can't resolve unresolved data
          symbols.

     ----lllloooogggg   ffffiiiilllleeee
          prints all messages to _f_i_l_e instead of the default action of
          printing all messages to the device ////ddddeeeevvvv////ttttttttyyyy  (if ////ddddeeeevvvv////ttttttttyyyy is
          unavailable, the system log (/_v_a_r/_a_d_m/_S_Y_S_L_O_G) is used instead).

     _r_l_d._d_e_b_u_g ooooppppttttiiiioooonnnnssss

     The following additional options are available when the appropriate
     _RLD_PATH environment variable is set appropriately to /usr/lib/rld.debug
     (for n32, _RLDN32_PATH to /usr/lib32/rld.debug.  for 64, _RLD64_PATH to
     /usr/lib64/rld.debug).






                                                                        PPPPaaaaggggeeee 4444






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     ----qqqquuuuiiiicccckkkkssssttttaaaarrrrtttt____iiiinnnnffffoooo
          Tells user whether quickstart has failed.

     ----iiiinnnntttteeeerrrraaaacccctttt
          _r_l_d interactively prompts the user on stdin to fix problems in the
          link (e.g. _r_l_d will ask the user to provide a full pathname for a
          missing shared object.)

     ----ttttrrrraaaacccceeee
          generally shows the flow of code in _r_l_d itself and prints individual
          symbol actions.

     ----vvvv   generally prints _r_l_d actions at the level of the DSO, not at the
          symbol level.  ----vvvv is less verbose than ----ttttrrrraaaacccceeee.

     ----ddddeeeebbbbuuuugggg ssssyyyymmmmbbbboooollll
          prints a verbose description of the actions taken resolving all
          symbols(the option is those two literal words: there is no provision
          for tracing the actions on only selected symbols).  This produces
          lots of output so it is normally most useful to also use ----lllloooogggg ffffiiiilllleeee
          to direct the _r_l_d output to _f_i_l_e.

     RRRRuuuunnnnttttiiiimmmmeeee lllliiiinnnnkkkkeeeerrrr eeeennnnttttrrrryyyy ppppooooiiiinnnnttttssss

     _r_l_d is entered when a program using dso is started via _e_x_e_c() and through
     lazy text resolution during program execution. Before exiting, programs
     or objects need to call __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__S_H_U_T__D_O_W_N) to ensure that the
     program executes all of the code specified by -_f_i_n_i flag to _l_d(1).  The
     __e_x_i_t(2) library routine calls __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__S_H_U_T__D_O_W_N).  Any call
     to __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__S_H_U_T__D_O_W_N) runs the -_f_i_n_i code on all objects so
     it cannot safely be done just anywhere!  As is mentioned below in this
     document, __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__S_H_U_T__D_O_W_N) is not a call any application
     should make: it is for the system developers only.

     SSSSyyyysssstttteeeemmmm ddddeeeevvvveeeellllooooppppeeeerrrr''''ssss iiiinnnntttteeeerrrrffffaaaacccceeee

     _r_l_d keeps a doubly linked list of structures and crt1.o contains a
     pointer to the head of the list of obj structures called ___r_l_d__o_b_j__h_e_a_d .
     In an o32 executable, this points to a linked list of objList structures
     (/usr/include/obj_list.h).  each of which has a 'data' element which is a
     pointer to a 'struct obj' (/usr/include/obj.h) (even though the field is
     not declared as a pointer).  In an n32 executable, ___r_l_d__o_b_j__h_e_a_d points
     to a linked list of Elf32_Obj_Info structures (/usr/include/objlist.h).
     In a 64-bit executable, ___r_l_d__o_b_j__h_e_a_d points to a linked list of
     Elf64_Obj_Info structures (/usr/include/objlist.h).  The 'oi_magic'
     element of each Elf32_Obj_Info or Elf64_Obj_Info is all-bits-on
     (0xffffffff) to make it easier to determine which list type is in use a
     32-bit executable.

     UUUUsssseeeerrrr eeeennnnttttrrrryyyy ppppooooiiiinnnnttttssss





                                                                        PPPPaaaaggggeeee 5555






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     The interface described below is for system development only.  It is not
     recommended nor supported for use in end-user code.  It is described here
     for the benefit of system developers.

     #_i_n_c_l_u_d_e <_r_l_d__i_n_t_e_r_f_a_c_e._h>
     _v_o_i_d *__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(_E_l_f_3_2__W_o_r_d _o_p_e_r_a_t_i_o_n, ...)

     Here is a list of currently defined operations:

     (_i_n_t)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__S_H_U_T__D_O_W_N)

          This function calls the routine specified by the -_f_i_n_i flag to _l_d(1)
          on all open DSOs (and the main program) in the reverse of the order
          that the -_i_n_i_t sections were run.

     (_c_h_a_r *)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__F_I_R_S_T__P_A_T_H_N_A_M_E)

          This function returns the string "MAIN" and resets an internal
          pointer inside of rld to set up for calls to This interface is not
          thread-safe: multiple threads doing this will get erroneous results.
          Any call to __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__M_O_D_I_F_Y__L_I_S_T,...)  after calling
          __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__F_I_R_S_T__P_A_T_H_N_A_M_E) and before calling
          __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E) will interfere with the
          correctness of the __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E) returns.
          __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E). Any operation (including
          delay-loading a DSO as a result of lazy-function-evaluation) that
          causes the DSO list to be altered may interfere with the correctness
          of the __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E) returns.

     (_c_h_a_r *)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E)

          This function returns the next pathname in _r_l_d's object list and
          increments its internal pointer. It returns NULL when rld reaches
          the end of the list.  This interface is not thread-safe: multiple
          threads doing this will get erroneous results.  Calls to
          __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E) cannot be interspersed with
          calls to __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__M_O_D_I_F_Y__L_I_S_T,...  as doing so will
          interfere with the correctness of the
          __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E) returns.  Any operation
          (including delay-loading a DSO as a result of lazy-function-
          evaluation) that causes the DSO list to be altered may interfere
          with the correctness of the __r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_E_X_T__P_A_T_H_N_A_M_E)
          returns.

     (_c_h_a_r *)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__M_O_D_I_F_Y__L_I_S_T, _E_l_f_3_2__W_o_r_d _o_p_e_r_a_t_i_o_n, _c_h_a_r
     *_o_r_i_g_i_n_a_l__p_a_t_h_n_a_m_e, _c_h_a_r *_n_a_m_e)

          This function allows users to link and unlink objects.  When users
          insert or add an object, they must specify the new object in _n_a_m_e.
          They may specify a full path or take advantage of _r_l_d's searching
          mechanism. Users are not allowed to insert before MAIN. If
          _o_r_i_g__p_a_t_h_n_a_m_e is zero, _r_l_d will operate on the last element in the



                                                                        PPPPaaaaggggeeee 6666






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



          list.  The exact function performed depends on the parameter
          _o_p_e_r_a_t_i_o_n, which can take the following values:

               __R_L_D__O_P__N_O_N_E does nothing.

               __R_L_D__O_P__I_N_S_E_R_T adds a new object specified by _n_a_m_e before the
               object specified by _o_r_i_g__p_a_t_h_n_a_m_e. Objects cannot be added
               before _m_a_i_n().

               __R_L_D__O_P__A_D_D adds a new object specified by _n_a_m_e after the
               object specified by _o_r_i_g__p_a_t_h_n_a_m_e. If _o_r_i_g__p_a_t_h_n_a_m_e is omitted,
               the new object will be added at the end of the object list.

               __R_L_D__O_P__D_E_L_E_T_E deletes _o_r_i_g__p_a_t_h_n_a_m_e from the object list.

               __R_L_D__O_P__R_E_P_L_A_C_E replaces _o_r_i_g__p_a_t_h_n_a_m_e with the object
               specified by _n_a_m_e in the object list.

     (_c_h_a_r *)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__A_D_D_R__T_O__N_A_M_E, _E_l_f_3_2__A_d_d_r _a_d_d_r_e_s_s)

          This function returns the symbol name of the address passed in as
          argument, NULL if no symbol corresponds to that address in the
          current process.  In a 64-bit application, the second argument is of
          type Elf64_Addr.

     (_E_l_f_3_2__A_d_d_r)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__N_A_M_E__T_O__A_D_D_R, _c_h_a_r *_n_a_m_e)

          This function returns actual address of _n_a_m_e. It returns NULL if _r_l_d
          cannot find the passed argument.  In a 64-bit application, the value
          returned is of type _E_l_f_6_4__a_d_d_r).


     (_c_h_a_r *)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__V_E_R_S_I_O_N__E_X_P_E_C_T_E_D, _c_h_a_r *_s_o_n_a_m_e)

          This function returns the version string in MAIN's liblist entry for
          _s_o_n_a_m_e.

     (_E_l_f_3_2__A_d_d_r)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__S_P_R_O_C__N_O_T_I_F_Y)

          This function signals to rld that sproc has been called and that rld
          has to worry about multiple sproc threads.  The call is made by
          _l_i_b_c._s_o.

     (_E_l_f_3_2__A_d_d_r)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__S_H_U_T_D_O_W_N__T_H_R_E_A_D)

          This function was intended to signal to rld that a thread is trying
          to exit.  Currently does nothing.

     (_E_l_f_3_2__A_d_d_r)__r_l_d__n_e_w__i_n_t_e_r_f_a_c_e(__R_L_D__S_P_R_O_C__F_I_N_I)






                                                                        PPPPaaaaggggeeee 7777






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



          This function signals to rld that multiple _s_p_r_o_c(2) threads support
          can be turned off.  It is called on behalf of, and in, the child
          process after a _f_o_r_k(2) by the _f_o_r_k code in _l_i_b_c._s_o.

EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
     Here are some csh aliases for control of rld tracing that you may find
     useful.  Notice that there are three sets of tracing aliases, one for
     each ABI (o32, n32, 64).  See _f_i_l_e(_1) for how to identify the ABI of a
     particular executable.

          #  trace o32 rld issues
             alias ra     \
                'setenv _RLD_PATH /usr/lib/rld.debug       ;'\
                'setenv _RLD_ARGS "\!*"                    ;'
             alias nora   \
                'unsetenv _RLD_ARGS                        ;'\
                'setenv _RLD_PATH /lib/rld                 ;'

          #  trace n32 rld issues
             alias ra32   \
                'setenv _RLDN32_PATH /usr/lib32/rld.debug  ;'\
                'setenv _RLD_ARGS "\!*"                    ;'
             alias nora32 \
                'unsetenv _RLD_ARGS                        ;'\
                'setenv _RLDN32_PATH /lib32/rld            ;'

          #  trace 64 rld issues
             alias ra64   \
                'setenv _RLD64_PATH /usr/lib64/rld.debug   ;'\
                'setenv _RLD_ARGS "\!*"                    ;'
             alias nora64 \
                'unsetenv _RLD_ARGS                        ;'\
                'setenv _RLD64_PATH /lib64/rld             ;'

     WWWWaaaattttcccchhhh RRRRLLLLDDDD wwwwhhhheeeennnn rrrruuuunnnnnnnniiiinnnngggg aaaannnn oooo33332222 bbbbiiiinnnnaaaarrrryyyy:::: ''''llllssss''''

          % ra -trace             <-- turns on tracing of o32 rld
          % ls
          27312:[rld] Entering RLD through MAIN
          27312:ls: [rld] mapped ls at 0x400000
          27312:ls: [rld] mapped /lib/libc.so.1 at 0xfa00000
          27312:ls: [rld] found _end in ls for libc.so.1 at 0x10007000
          27312:ls: [rld] number of objs in the objlist is 2
          27312:ls: [rld] Exiting RLD through MAIN
          RCS           libX11.so.2   libc.so       libl.a        setup
          acrt1.o       libXaw.a      libc.so.1     libm.a        sgicc.cfg
          crt1.o        libXext.a     libc.so.O     libmld.a      sgild.cfg

          % nora                  <-- turns off all o32 rld debugging options.






                                                                        PPPPaaaaggggeeee 8888






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     WWWWaaaattttcccchhhh RRRRLLLLDDDD wwwwhhhheeeennnn rrrruuuunnnnnnnniiiinnnngggg aaaannnn nnnn33332222 bbbbiiiinnnnaaaarrrryyyy:::: ''''cccciiii''''

          % ra32 -v               <-- turns on verbose mode in n32 rld
          % ci -l c.c
          14891:_RLD_ARGS = "-v"
          14891:_RLD_ROOT = /
          14891:LD_LIBRARYN32_PATH = none
          14891:ci: mapped ci at 0x10000000
          14891:ci: mapped /usr/lib32/libc.so.1 at 0xfa00000
          RCS/c.c,v  <--  c.c
          file is unchanged; reverting to previous revision 1.1
          done

          % nora32                <-- turns off all n32 rld debugging options.

EEEERRRRRRRROOOORRRR RRRREEEEPPPPOOOORRRRTTTTIIIINNNNGGGG
     Most error messages are written to /_d_e_v/_t_t_y, unless otherwise noted
     above.  If _r_l_d should encounter an error condition for a process which
     does not have a valid /_d_e_v/_t_t_y attached, it will write the messages to
     /_v_a_r/_a_d_m/_S_Y_S_L_O_G instead.  (The system log is written via calls to
     _s_y_s_l_o_g(2).)


CCCCHHHHAAAANNNNGGGGIIIINNNNGGGG RRRROOOOOOOOTTTT
     A copy of the device /_d_e_v/_z_e_r_o is essential to the operation of _r_l_d.
     Thus in most uses of _c_h_r_o_o_t(1), it will be necessary to put a copy of
     /_d_e_v/_z_e_r_o in the newly-created root.


SSSSEEEEEEEE AAAALLLLSSSSOOOO
     _l_d(1), _c_c(1), _d_l_o_p_e_n(3), _d_l_c_l_o_s_e(3), _d_l_s_y_m(3), _d_l_e_r_r_o_r(3), _s_g_i_d_l_a_d_d(3),
     _s_g_i_d_l_o_p_e_n__v_e_r_s_i_o_n(3), _s_g_i_g_e_t_d_s_o_v_e_r_s_i_o_n(3), _d_s_o(5), _g_p__o_v_e_r_f_l_o_w(5)

     Also see "System V Application Binary Interface" and "System V
     Application Binary Interface: MIPS Processor Supplement" and "MIPSpro N32
     ABI Handbook"

NNNNOOOOTTTTEEEESSSS
     Listing a particular DSO in ____RRRRLLLLDDDD____LLLLIIIISSSSTTTT is likely to lead to problems and
     failures unless all three environment variables are set.  A typical
     result is a message like "... rld: Fatal Error: Cannot Successfully map
     soname ...".  For example, consider a test app "a.out" which is o32 and a
     specific o32 DSO, /tmp/mydso.so:
         unsetenv _RLDN32_LIST _RLD64_LIST
         setenv _RLD_LIST "/tmp/mydso.so:DEFAULT"
     This will likely fail because some command (or the app itself) will
     attempt to fork/exec some n32 application and /tmp/mydso.so is o32, not
     n32.  ____RRRRLLLLDDDDNNNN33332222____LLLLIIIISSSSTTTT and ____RRRRLLLLDDDD66664444____LLLLIIIISSSSTTTT don't suffer from this as they are
     only interpreted in a single ABI each. See the description of ____RRRRLLLLDDDD____LLLLIIIISSSSTTTT
     earlier in this man page.  Adding
         setenv _RLDN32_LIST DEFAULT
         setenv _RLD64_LIST DEFAULT



                                                                        PPPPaaaaggggeeee 9999






RRRRLLLLDDDD((((1111))))                                                                  RRRRLLLLDDDD((((1111))))



     will fix the problem in this example.

DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS
     Here we explain a message from rld whose meaning is not apparent.

     The aggregate IEEE exceptions required (OEX_FPU_MIN) (0xnn) not as
     complete as the aggregate IEEE exceptions permitted
     (OEX_FPU_MAX>>8)(0xnn).

         As the executable and each DSO is accessed (before the app begins
         running) the .MIPS.options section (visible with _e_l_f_d_u_m_p -_o_p) is used
         to compute an aggregate set of floating point exceptions to enable.
         For example, use of the ----ttttrrrraaaappppuuuuvvvv flag to the compiler results in a
         request for invalid exception trapping be enabled.  Whereas use of
         certain high optimizations for -mips4 and -mips3 require that those
         exceptions be turned off so that speculative loads of floating-point
         values can be executed silently.  See compiler options
         -TARG:exc_max=[I][U][O][Z][V], -TARG:exc_min=[I][U][O][Z][V], and
         -TENV:X=0..5.

         Delay-loaded DSOs and dlopen()'d and sgidladd()ed DSOs are not
         factored in till the actual sgidladd/dlopen is called.  The
         OEX_FPU_MIN field of each object is OR'd with the others.  The non-
         zero bits represent the set of floating point exceptions that the app
         wants to catch (more precisely exceptions that some part of the app
         or a DSO want to catch).  The OR'd-together OEX_FPU_MIN fields are
         used to determine what set_fpc_csr() fields to set to 1 ( rrrrlllldddd never
         sets any set_fpc_csr() fields to zero).  The OEX_FPU_MAX field of
         each object is AND'd with the others.  The zero-bits represent
         floating-point exceptions that must not be caught (for example, if
         the code generator is issuing speculative loads, the invalid-value
         exception should not be caught).  If some bits are OFF in OEX_FPU_MAX
         that are ON in OEX_FPU_MIN that represents an impossible scenario:
         exceptions must be caught and simultaneously must not be.  For
         example, this could happen if object is compiled requesting trapping
         uninitialized variables and requesting requesting a high optimization
         resulting in the code generator issuing speculative loads.

         As each DSO is dlopen()ed or delay-loaded or sgidladd()ed or
         dlclose()ed these flags are recalculated.  If user or library code
         has changed the 5 exception-flag-enable fields from a previous
         setting by rrrrlllldddd then rrrrlllldddd updating of the exception-enable fields
         silently ceases for this execution.

         rrrrlllldddd never turns off exception-enable flags once it has turned them
         on.

         Use eeeellllffffdddduuuummmmpppp ----oooopppp <<<<oooobbbbjjjjeeeeccccttttnnnnaaaammmmeeee>>>> to see the OEX fields of an executable
         or DSO.






                                                                       PPPPaaaaggggeeee 11110000